Agil und instabil?

Moderne „agile“ Methoden gewinnen in der kommerziellen Software-Entwicklung immer mehr an Boden. Sie versprechen ein Plus an Funktionen bei gleich bleibendem Aufwand. Doch oft enden IT-Projekte auch mit den agilen Methoden in der Sackgasse, weil sie sich nur die vermeintlichen Rosinen aus Extreme Programming (XP) oder anderen neuen Ansätzen heraus picken. Mittel- und langfristig wirksame Erfolgsfaktoren wie systematisches Testen geraten so unter die Räder.

Dabei sind Ansätze wie XP testgetriebene Entwicklungsmethoden. Denn bevor Entwickler bei XP auch nur eine Zeile programmieren, definieren sie Testfälle. Sie sind die Basis der gesamten Entwicklung. Dieser „Test-first“-Gedanke ist das Ergebnis oft leidvoller Erfahrungen aus den Entwicklungsprojekten der vergangenen Jahrzehnte: Je früher die Qualitätssicherung (QS) beginnt, umso mehr reduziert sich der Aufwand im weiteren Projektverlauf.

So schreiben die Autoren von „www.extremeprogramming.org“: „When you create your tests first, before the code, you will find it much easier and faster to create your code. The combined time it takes to create a unit test and create some code to make it pass is about the same as just coding it up straight away. But, if you already have the unit tests you don’t need to create them after the code saving you some time now and lots later.“

Vor allem verhindere „Test first“ von Anfang an, dass eine Lücke zwischen Business-Anforderungen und implementiertem Code entstehe: „Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.“